Interrupt Service Routines

Topic: DMD0367

Help File Version: 2.10.0.636

Interrupt Service Routines

An interrupt is a signal generated by some event external to the CPU, which causes the CPU to stop what it is doing (stop executing the code it is currently running) and jump to a separate piece of code designed by the programmer to deal with the event which generated the interrupt request. This interrupt handling code is called an ISR (interrupt service routine). When the ISR is finished, the CPU returns to the code that was running prior to the interrupt, which then resumes running with no awareness that it has been preempted by the interrupt code. It is this ability to run the appropriate code for an external event at any point in time that is both the chief benefit of, and the potential source of difficulties from, interrupts.

In the Do-more CPUs, an interrupt service routine (ISR) is a code-block, whose execution is triggered by the reception of an Interrupt Trigger, which is configured through the System Configuration or through the INTCONFIG - Interrupt Configuration Editor. Interrupt Triggers define the external hardware event or timed event that constitutes the Interrupt, and associates an Interrupt Service Routine (ISR) that will be executed when that Interrupt Trigger is fired.

Cautions when Using Interrupts

Because ISRs are interrupting all of the normal processing that happens during a PLC scan - this includes all communication processes - it is imperative that the ladder logic in the ISR be kept to a minimum. If possible use only contacts, coils and Math operations.

Interrupts are intended to be used to manage processes that require precision, either by minimizing the latency from when a signal is received until the code that handles that signal is executed, or by performing operations at very precise time intervals. They are not intended to prioritize the execution of lots of ladder logic. When done properly Interrupts can be a great tool to handle intra-scan events that need immediate servicing. Done improperly they can wreak havoc on your PLC scan. To that end we've compiled a list of things that Interrupts can and cannot do to help you use them wisely.

Interrupt Triggers cannot interrupt the execution of any ISR that is already running.

If the same Interrupt Trigger fires while it's associated ISR is running that Trigger will be missed; it will not immediately run it's associated ISR again.

If a different Interrupt Trigger fires while an ISR is running, the associated ISR for this Trigger will run when the other ISR completes.

It one or more Interrupt Triggers fire at the same time, their associated ISRs will run in the following order: Event 0, Timer 0, Match 0, Event 1, Timer 1, Match 1, Event 2, Timer 2, Match 2, Event 3, Timer 3, Match 3.

Not all instructions are supported in ISRs, for example looping instructions and asynchronous instructions are not supported. Any unsupported instructions will be flagged when you download the project to the PLC. Refer to the Instruction Set List which shows which instructions are NOT allowed with the symbol.

There is no Termination Logic like there are with other code-blocks, meaning that, unlike Output Coils in other "containers" that have Termination Logic, any Output Coils that are turned ON inside the ISR will remain ON after the ISR ends.

Interrupt Overload Detection

Configuring interrupts that will happen very frequently, or having multiple interrupts that will consume a significant amount of time each time they process can consume enough of the scan time to trip the watchdog timer. To help mitigate the potential of this happening, the CPU will accumulate the runtime of all of the interrupt routines during a scan, and if that accumulated time exceeds 10ms the CPU will suspend interrupt processing for the remainder of that scan and set $ISROverload (ST155) ON to indicate the configured interrupts are consuming too much of the CPU scan. Normal interrupt processing will resume on the following scan.

Interrupt Service Routine Code-Block Configuration

Any time a new Interrupt Service Routine is created the following dialog will open where you will specify the operating parameters of the code-block that is associated with the ISR.

Name - the name of the code block that is executed when the associated Interrupt Trigger event occurs. This name will also be used as the name of the structure you will use to interact with this ISR in the ladder logic of a project. The ISR name can be 1 to 16 characters in length and consist of any combination of alphanumeric characters and underscores ('_', 'a-z', 'A-Z', 0-9), no spaces or punctuation marks are allowed, and must begin with a letter or an underscore.

Retentive Interrupt Structure (affects System Configuration) - enable this selection to make the ISR's structure retentive, meaning the structure and all of its member fields will retain their values through a power-cycle.

ISR ID: xx - a unique number assigned when the ISR is created. There can be up to 32 ISRs in a project.

Notice the TimeSlice option is missing. This is because Interrupt Service Routines do not allow the use of looping instructions (FOR / NEXT, WHILE / WEND, REPEAT / UNTIL, GOTO / LABEL).

These optional selections control accessibility and visibility of a code-block within Do-more Designer. The programmer can select to secure the contents of user-created code-blocks from being viewed and / or edited by means of a password and optionally encrypting the code-block contents. This dialog will show the current state of the protection and allow the programmer to set the protection level that will be enforced once the dialog is closed or the project is closed.

Full Access - (the default value) - the contents of the code-block can be viewed and modified without restriction.
Unlocked for this Project Session - the code-block is password protected, and once the password is correctly entered it's contents can be viewed and modified. The code-block will be locked automatically after the project session is closed.
Locked - the code-block name will be listed in the Control Logic group of the Project Browser, and placeholders for each rung will be present, but the contents of the code-block is password protected and can only be modified on a per-operation basis, e.g. changing the code-block configuration, which requires entering the correct password.

The code-block will be locked automatically after the Do-more Designer session is closed. The code-block will be displayed in the Project Browser with "(Locked)" appended to the code-block name. Any attempt to access a code-block that is locked will open a dialog that will prompt for the password.

The contents of code-blocks that are locked will not be accessible to the normal operations of the programming software, for example Search / Replace, Program Check, Compare Programs, etc. So, for obvious reasons, code-blocks should be unlocked during editing sessions and then locked only when the project session is about to be ended.

Set Password - click this button to open the Modify Code-Block Password dialog. Code-block passwords must be at least 4 characters in length, can be any reasonable length, and can contain any combination of letters, numbers, and characters. Once a password has been set for a code-block it is encrypted as part of the code-block.

Current Password - will be disabled if no password currently exists, otherwise enter the current password for this code-block.

New Password - enter the new password for this code-block.

Confirm New Password - re-enter the password to confirm.

Click Clear Password to clear the existing password.

Click Set Password to save the new password. It is imperative that the programmer remember the code-block password. Once a password has been set for a code-block it is encrypted as part of the code-block, and therefore it will be impossible to retrieve a lost code-block password.

Click Cancel to exit without saving the new password.

Click Set Protection Level to save the protection level changes.

Click Cancel to exit without saving any protection level changes.

Interrupt Service Routine Code-Block Structure Fields

Each Interrupt Service Routine has an associated code-block, and that code block has an associated structure with fields that are used interact with the ISR from the ladder logic:

.HasRun - (Read / Write) - a Bit that will be ON if the ISR was run at least one time since the last Program -to- Run mode change.

.Inhibit - (Read / Write) - a Bit that can be set ON to prevent the ISR from being executed when the Interrupt Trigger fires.

.RunCounter - (Read / Write) - a Word location that contains the number of time the ISR has been executed since the last Program -to- Run mode change.

.Latency - (Read / Write) - a Word location that contains the amount of time (in microseconds) between when the Interrupt Trigger was fired and the execution of the ISR began.

.ExecutionTime - (Read / Write) - a Word location that contains the amount of time (in microseconds) the ISR took to execute.

Manually Suspending All Interrupts

Interrupt processing can be suspended through the use of the Suspend Interrupts (INTSUSPEND) instruction. which disables all interrupt processing in the CPU - both external hardware events and timed events.

Normal Interrupt Processing can be restarted with the INTRESUME - Resume Interrupts instruction.

Changing Interrupt Configuration at Runtime

New Interrupt Triggers can be created, and the configuration of existing Interrupt Triggers can be changed at runtime through the INTCONFIG - Interrupt Configuration Editor instruction.

Existing Interrupt Triggers can be deleted with the INTDECONFIG - Deconfigure Interrupt instruction.